Analysis of PCI DSS v4.0 – Part II: Requirements 1 and 2

In this second part of the series “Analysis of PCI DSS v4.0” a review shall be carried out of requirements 1 and 2 of the standard, which are part of the group “Build and Maintain a Secure Network and Systems”, aimed at controlling incoming and outgoing network traffic from the environment and the secure configuration of system components; or hardening.

As indicated in the first part of this series of articles, it is important to note that these requirements have been renamed in version 4.0 of the standard to adapt to technological changes in security controls and to expand the scope of their applicability.

Changes in the names of PCI DSS requirements 1 and 2

Requirement 1: Install and Maintain Network Security Controls

The overcrowding of the use of virtualisation technologies (including software-defined networks – Software Defined Networks or SDN) and containers, as well as network infrastructures provided by cloud service providers (cloud) have significantly impacted the first PCI DSS requirement. In fact, this change can be seen in the renaming of the requirement and the removal of the term ‘firewall’, which has been present since the first version of the standard.

However, these changes were no surprise, as the PCI SSC had already advanced some of them in the document. Information Supplement – Cloud Computing Guidelines, published in April 2018, where a series of technical security considerations were analyzed in the implementation of multi-user environments in the cloud (Multi-tenant cloud environment) and emerging architectures such as the Internet of Things (Internet of Things – IoT) or Fog Computing, and technologies such as Software Defined Networking (SND), containers and Virtual Desktop Infrastructure (VDI). All these technological changes are accompanied by new threats and new risks that were not being managed correctly or that did not completely adapt to the criteria established in version 3.2.1 of PCI DSS.

That is why In PCI DSS version 4.0, the traditional concept of “firewall” has been dispensed with and replaced by the concept of “firewall”. Network Security Controls (NSCs), a much broader concept encompassing not only firewalls previously named, but also to any other network technology that allows controlling network traffic between two or more logical or physical network segments based on predefined rules or policies.

Difference between the concept of ‘Firewall’ and ‘Network Security Control’

Generally speaking, this requirement retains the same organization of controls seen in PCI DSS v3.2.1 but some of them have been added or changed to adapt them to the concept of NSCs. Some of the most representative changes are:

• Required configuration standards for NSC filtering rules (1.2.1)
• Changes to network connections and NSC configurations (1.2.2) must be implemented following the PCI DSS change management methodology, as specified in requirement 6.
• In the case of the Network Diagrams (1.2.3), good practices have been added, among which are the labelling of network segments, the identification of security controls that provide segmentation and their details (control name, model, version, etc.), inclusion of all components in the scope, labelling of areas out of scope and information on changes to the document (date of the last update, responsible for the change, approver of the change and an explanatory legend of the diagram).
• In the case of the Flowcharts (1.2.4), it is indicated that this diagram complements the network diagram and it is recommended to include all processes (authorization, capture, settlement, returns, refunds, etc.) and card data flows, including those involving physical means.
• Only permitted identified services, protocols and ports, approved and with a defined business need (1.2.5), including additional controls for ports considered unsafe (1.2.6).
• Must be carried out a six-monthly review of the NSC configuration to confirm that they are relevant and effective (1.2.7).
• If the NSCs use configuration files, these must be protected against unauthorised access and consistent with the active network configuration (1.2.8).

Likewise, the terminology of the network segments to be protected has been clarified, aligning it with the criteria described in the document Information Supplement – Guidance for PCI DSS Scoping and Network Segmentation. In that sense, the intention is for it to deploy a network security control (Network Security Control – NSC) between environments with different levels of trust (including internal networks). From this perspective, two main network blocks are identified:

• Reliable networks (trusted networks): Any network that is under the control or management of the entity and that complies with the applicable PCI DSS requirements. This category includes CDE and systems connected to or likely to impact CDE security.
• Unreliable networks (untrusted networks): Any network outside the entity's control, including the Internet, dedicated communication channels, wireless networks, Internet Service Provider (ISP) networks, including mobile networks and third-party networks. It is also clarified that, if a network is out of reach of PCI DSS, such a network should be considered as an unreliable network.

Thus, the traffic filtering rules that must be implemented by NSCs must follow the following criteria:

Criteria to follow in NSCs policies or rules

An interesting theme in this version of the standard is that the obligation to implement a Demilitarized Network (DMZ) as a network segment to limit incoming traffic access (1.3.1 in PCI DSS 3.2.1) has disappeared, although it is now recommended as a good practice. However, if a DMZ is implemented and this segment processes or transmits payment card data, it should be considered as part of the CDE.

Requirement 2: Apply Secure Configurations to All System Components

As with requirement 1, this requirement was renamed to make the applicability of secure configuration controls more flexible, emphasizing that not only do you have to change the default values, but you also have to remove unnecessary software, functions, and accounts, and deactivate or eliminate unnecessary services. Also, emphasis is placed on the fact that this requirement applies not only to “traditional” systems but to any other system accessed through a cloud subscription service (cloud).

Among the changes applied, this requirement should be highlighted the following:

• The development of Secure Configuration Standards for all system components (2.2.1), including cloud systems. In this way, as a reference, it is also added to the Cloud Security Alliance (CSA).
• Allowed the use of default accounts of manufacturers (vendors), as long as your default password is changed (2.2.2). Otherwise, these accounts must be removed or deleted. This is an important change from PCI DSS v3.2.1, since in that version of the standard simply these default accounts had to be deleted or removed and any exceptions had to be managed through compensatory controls.
• Clarification of the applicability of the concept of “primary function” (2.2.3), allowing the coexistence of different main functions with different levels of security in the same system as long as they are isolated from each other or as long as they are all secured at the same level as the one with the highest level of security. This concept had already been discussed earlier in the document. Information Supplement – PCI DSS Virtualization Guidelines June 2011, focused on virtualization technologies, but PCI DSS version 4.0 has already been explicitly included.
• They should only be allowed services, protocols, daemons and other functions necessary, removing or disabling all others (2.2.4), justifying and adding additional controls to those considered unsafe (2.2.5).
• Only the administrative access other than by console (non-console) as long as it is encrypted using robust cryptography. This includes not only traditional (browser-based) administrative interfaces but also access via application programming interfaces (Application Programming Interfaces – APIs).
• Additional controls are added in the secure configuration process of wireless environments (2.3.1), including the change of encryption keys of wireless networks that transmit card data or connected to the CDE if any personnel with knowledge of them leave the company or if the key is compromised or suspected.

Finally, component inventory control (2.4 in PCI DSS v3.2.1) has moved to requirement 12, a location more consistent with its objective.

The following article will analyze the requirements 3 and 4 of PCI DSS, oriented to the security of card data during its storage and transmission.

References

• • Information Supplement – Cloud Computing Guidelines https://www.pcisecuritystandards.org/pdfs/PCI_SSC_Cloud_Guidelines_v3.pdf
  • Information Supplement – Guidance for PCI DSS Scoping and Network Segmentation https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1_1.pdf
  • Information Supplement – PCI DSS Virtualization Guidelines https://www.pcisecuritystandards.org/documents/Virtualization_InfoSupp_v2.pdf